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REMARKS/ARGUMENTS 

In an Office Action dated December 20, 2004, the drawings were objected to; the 
specification was objected to for failing to provide antecedent basis; claim 13 was 
objected to; claims 1, 2, 10-12, 20 and 29 were rejected under § 102 over Muller; and the 
remaining claims were rejected under § 103 over Muller and various other references. 
Applicants submit that the claims are allowable. 



Drawings 

New drawings have been provided to correct the informalities. 



Specification Objection 

Applicants respectfully traverse the objection to the specification. World Wide 
Name or WWN is submitted as being a well known term to one skilled in Fibre Channel. 
Reference is made to the Storage Networking Industry Association (SNIA) website. A 
suggested URL is www.SNIA.org/education/dictionary/w/ where World Wide Name 
(WWN) and other related items are defined as: 

World Wide Name (WWN) 

1 . A 64-bit unsigned Name_Identifier which is worldwide unique, cf. 
Fibre Channel Name 

2. A unique 64 bit number assigned by a recognized naming authority 
(often via block assignment to a manufacturer) that identifies a 
node process or node port. See WWNN and WWPN. Abbreviated 
WWN. A WWN is assigned for the life of a connection (device). 
Most networking physical transport network technologies use a 
world wide unique identifier convention. For example, the 
Ethernet Media Access Control Identifier, often referred to as the 
MAC address. 

World Wide Node Name (WWNN) 

A globally unique 64-bit identifier assigned to each Fibre Channel 
node process. 
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World Wide Port Name (WWPN) 

A globally unique 64-bit identifier assigned to each Fibre Channel 
port. Fibre Channel ports' WWPN are permitted to use any of 
several naming authorities. Fibre Channel specifies a Network 
Address Authority (NAA) to distinguish between the various name 
registration authorities that may be used to identify the WWPN. 

Applicants acknowledge that this reference is contemporary but offer to find references 
having dates before April 23, 2001, if so required, to prove the well known nature at the 
time of filing the priority document. 

Claim Objection 

Claim 13 has been amended to properly depend from claim 12. 

General Background Discussion 

To assist in the handling of the application, Applicants believe some general 
background discussion will be helpful. In order delivery of frames is one item that 
distinguishes Fibre Channel and Ethernet. 1 In Ethernet, particularly TCP/IP uses, it is 
assumed that frames will be received out of order due to routing issues. However, in 
Fibre Channel in order delivery is effectively required. Fibre Channel data is transferred 
in sequences, with each sequence having the frames transmitted in a particular order. In 
switching and routing the frames in the sequence, care must be taken to ensure in order 
delivery. This is not an easy requirement and affects many portions of switch and router 
design. This is particularly true if attempting to combine links between two switches into 
true trunks. Ethernet units can easily form trunks from effectively parallel links because 
there is no in order requirement. Routing and actual output is simplified for Ethernet 
without this requirement. But, as noted, Fibre Channel has this in order requirement so 
simple trunking like done in the Ethernet world cannot be done. Even slight skews 



While out of order delivery is theoretically allowed in certain classes in Fibre Channel, in order delivery is 
required in practice. 
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between two links can quickly lead to out of order receipt of frames. Systems according 
to the present invention can perform true trunking with in order receipt of frames across 
the links in the trunk. The claims cover various aspects of the present invention. 

$ 102 Rejection 

Claims 1,2, 10-12, 20 and 29 were rejected under § 102 over Muller. Applicants 
respectfully traverse the rejection. 

Claim 1 

Applicants respectfully submit that the trunking master ports required in claim 1 
are not shown, taught or suggested by Muller. 

The Office Action states that the learning circuit configured to modify the 
forwarding database selects trunking ports to be trunking masters. Applicants submit that 
this mischaracterizes the function of the learning circuit. As understood by Applicants, 
the learning circuit simply determines if the packet should be forwarded based on a port 
value or a trunk value based on Mode 1 or Mode 2 device connections. The learning 
module simply sets bits in a mask to cause port or trunk values to be used. See Fig. 6C. 
The learning module and/or the filtering module actually perform load balancing by 
performing hash operations. Because hash operations are to develop uniform balancing, 
each port in a trunk will be chosen uniformly. Thus all of the ports are shown as being 
identical in Mueller if in a trunk. As they are all identical, none can be a trunking master 
port as required in claim 1 . 

Applicants submit that Muller does not indicate how ports are added to a trunk 
group. Muller is focused on learning the MAC addresses associated with the other end of 
each link and then performing a proper trunk routing decision based on the type of device 
connected to the port. Muller always knows a port is in a given trunk. It does not 
indicate how this is known, it just relates to proper routing over a trunk. Thus Applicants 
suggest Muller cannot suggest any technique for adding a port to a trunk group. 

Claim 1 further requires that the trunking master control the frames routed over 
the trunked group. As noted above, which port in a trunk to use in Mueller is based on 
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the hash output. No port in the trunk controls any other port in the trunk. The ports are 
identical. Thus this second requirement of claim 1 is not shown, taught or suggested by 
Muller. 

Claim 2 

The Office Action generally referenced ports in Fig. 1 of Muller to reject claim 2. 
Applicants respectfully traverse this rejection. Muller describes Ethernet connections. 
See col. 3, lines 49-51 and the frequent references to MAC addresses, including col. 1, 
lines 35-40. The claimed Exports of claim 2 are Fibre Channel ports. Clearly Fibre 
Channel is a different networking protocol than Ethernet. Thus the rejection of claim 2 
under § 102 is improper. 

Claim 10 

This claim was rejected for similar reasons to claim 1, except the Office Action 
appears to indicate that all selected ports of the trunk are trunking master ports. 
Applicants submit that the arguments of claim 1 apply here. Applicants also respectfully 
submit that characterizing all selected ports as trunking master ports ignores any meaning 
for the word "master." Claim 1 includes specific requirements for trunking master ports. 
Muller does not show such requirements and clearly does not show that each port has the 
required capabilities as apparently alleged in the Office Action.. 

Claim 11 

Applicants first note that for claim 1 1 an input port has been defined to be a 
trunking master port. This contradicts the elements of Muller defined by the Office 
Action as trunking master ports in claim 1 (output ports as best understood) and claim 1 0 
(clearly output ports). It is a fundamental point that the definition of an item cannot 
change between claims. Thus this forms a first reason the rejection of claim 1 1 is 
improper. 

Secondly, claim 1 1 requires enabling a frame to be received at the second switch 
with "in-order" delivery. The Office Action does not address this required claim 
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limitation. Muller does not speak to this limitation because TCP/IP and Ethernet to 
which Muller relates have no consideration or requirement of "in-order" delivery. "In- 
order" delivery is discussed above. Thus Applicants submit that Muller does not show 
"in-order" delivery and that the Office Action does not address this claim limitation. 

Claim 20 

Claim 20 requires the "transmit port routing frames received at the first switch 
across the group to the second switch." The Office Action references col. 1, line 63 to 
col. 2, line 12, which just discusses the learning logic which associates ports with trunks, 
but does not actually perform routing. The reference to col. 9, lines 3-16 relates to the 
filtering logic, shown better in Fig. 7B. While the filtering logic may handle the load 
balancing, Muller clearly indicates that the learning and filtering logic are located within 
the switch fabric. See col. 7, line 62 to col. 8, line 42 and Fig. 4. Thus any routing 
decisions are done in the switch fabric, as opposed to the claim requirement that the 
transmit port handle the routing of frames across the group. Therefore Applicants 
respectfully submit that Muller does not show, teach or suggest a claim limitation and the 
rejection should be withdrawn. 

§ 103 Rejections 

The remaining claims were rejected under § 103 over Muller and various 
references. Applicants respectfully traverse the rejections. 

Claim 3 

Claim 3 requires two ports to exchange link parameters and then determining if 
two identifiers exist, one higher than the other. Applicants submit that neither Muller nor 
Kadambi show these claim requirements. Exchanging link parameters (ELP) is a process 
wherein there is a communication between the two connected ports. See Fig. 4 of the 
present applicant and pages 49 - 53 of the FC-SW specification provided in the 
accompanying Information Disclosure Statement. Neither Muller nor Kadambi show any 
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similar communication process. The portions or operations mentioned in the Office 
Action are all internal to the given switch in Muller and Kadambi. 

Then there clearly cannot be any teaching or suggestion of comparing identifiers 
as there is not even the requisite ELP. 

Therefore Applicants submit claim 3 is allowable, both for being dependent on 
allowable claim 1 and for the reasons mentioned here. 

Claim 4 

Claim 4 is allowable as being dependent on allowable claims 1 and 3. In addition, 
as stated above, a WWN is a Fibre Channel term. Both Muller and Kadambi are 
Ethernet-based disclosures and therefore do not teach or suggest the identifiers being 
WWNs. 

Claim 5 

Claim 5 was rejected over Muller and Bertin. Applicants respectfully traverse the 
rejection. 

As a first point, while Bertin may maintain propagation delay values for each link, 
this does not teach or suggest determining one way skew values for links associated with 
the trunked group. Bertin' s concern is overall transit time or variation. Bertin develops 
each possible path a node at a time, checking to see if the path still meets requirements. 
See col. 12, line 59 to col. 13, line 8. Bertin never compares the propagation delay of one 
link versus the other in making a routing selection. That type of comparison is simply 
not relevant to Bertin. So, while the data may be present for Bertin to theoretically 
determine link skew, there is one suggestion or teaching of a reason to do so. Such 
suggestion would come only in hindsight where the teachings and claims of the present 
application are considered. 

Further, there is no suggestion in either Muller or Bertin to use a skew value to 
add a port to a trunk group. As noted above, Muller does not indicate how ports are 
added to a trunk group, much less using a skew value in that determination. Bertin does 
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not add this teaching or suggestion because Berlin does not involve trunks and never 
suggests determining a link skew value. 

Claim 6 

Claim 6 is allowable as being based on allowable claims 1 and 5. Further, the 
arguments of claim 5 relate here. Bertin may maintain link speeds but does not suggest 
comparing two speeds of links for a trunking determination. The skew arguments from 
claim 5 apply directly. Further, the arguments about Muller not teaching how a port is 
added to a group applies. Muller merely is related to routing for trunks, not assigning to 
trunks. Thus, there would be no teaching or suggestion in Muller to use speed or skew 
values in adding ports to a trunk group. 

Claim 14 

Claim 14 has been amended to better conform to the teachings of the present 
invention. As noted above, Muller does not indicate how or when ports are added to a 
trunked group. Muller simply knows the ports are in a trunked group. Bertin does not 
teach trunks and so would not suggest when to add ports to a trunked group. Therefore 
Applicants submit claim 14 is allowable. 

Claims 8 and 9 

Claims 8 and 9 have been cancelled to prevent possible double patenting issues 
with co-pending Application No. 10/135,615, a divisional of this application. 

Claim 15 

Applicants submit that the arguments of claim 1 apply equally here. Muller does 
not teach or suggest a master transmit port or a master receive port. Muller clearly does 
not teach or suggest queuing the frames received at the transmit ports through a queue 
associated with the master transmit port. 

Chapman does not provide this missing teaching. Applicants first reference 
Chapman's title: Method and Apparatus for Single IP-Layer Bandwidth Allocation 
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Using Ingress Control of Egress Bandwidth. Applicants reference col. 10, line 50-54 
where Chapman clearly indicates that the various queues are set up at the local memory 
of the input or receive port. Thus the queuing is done at the receive ports, not at the 
master transmit port. Therefore, Applicants submit that Chapman actually teaches away 
from the requirements of claim 15. 

Claim 16 

Applicants respectfully traverse this rejection. Applicants submit that Chapman 
does not teach queuing using a master receive port but rather that each input or receive 
port in the trunk maintains its own queue. Therefore Chapman does not teach or suggest 
a required claim element. 

Claim 17 

The arguments made with regard to claim 1 1 with regard to "in-order" apply 
equally here. As in claim 11, the "in-order" requirement has not been addressed. 
Applicants submit that claim 1 7 is allowable for this further reason. 

Claim 21 

Applicants traverse the rejection of Claim 21. Claim 21 requires that the transmit 
port route the frames (in claim 20) and that the queuing logic enables the frames to be 
routed through the transmit port and across the group. Chapman does not teach or 
suggest these requirements. As noted above, Chapman queues on the input or receive 
port. Further, Chapman routes centrally, not at the transmit port. See col. 15, lines 1 8-30 
where routing is done prior to switching. Thus Chapman teaches against the claim 
limitations. 

Claim 25 

Please refer to the arguments made with respect to claim 2. 
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Claim 30 

Applicants repeat the arguments of claims 1, 15, 20 and 21 with respect to claim 
30. None of Muller, Chapman or Bertin teach or suggest master transmit and master 
receive ports as required or the required queuing. Applicants submit that claim 30 is 
allowable. 

Claim 23 

Applicants traverse the rejection of claim 23. Claim 23 requires a timer used in 
conjunction with a list associated with the transmit port to ensure "in-order" delivery of 
frames. Applicants request reference to paragraph 51 of the present application. In the 
preferred embodiment the timers bind or block transmit operations until the relevant link 
skew is accommodated. A mere timer to measure propagation does nothing like this. A 
propagation delay timer would do nothing to ensure "in-order" delivery. Thus the mere 
presence of a timer to measure propagation delay does not begin to teach or suggest 
various requirements of claim 23. 

Claim 24 

Applicants traverse this rejection. The Office Action defines the timer in claim 23 
to be for maintaining propagation delay then in claim 24 the Office Action references a 
time to live parameter. These two items in Bertin are completely unrelated, yet the 
Office Action attempts to use them in some combination. As claim 24 is dependent on 
claim 23 and further defines the timer of claim 23, this reference to a completely different 
item is improper and the rejection must be withdrawn. 

New Claims 

New claims 31 to 45 are provided. Applicants submit that the claims are 
allowable. Each of the dependent claims requires that frames are distributed evenly and 
be transmitted so that they are received in order at the receiving ports. Applicants have 
discussed "in-order" above. As noted above, none of the cited references disclose, teach 
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or suggest in order delivery. Therefore Applicants submit that the new claims are 
allowable for that reason. 

A series of new dependent claims require determining skew values for the links 
and using these skew values to control timing of frame transmission. As noted above, 
none of the cited references determine, teach or suggest determining skew values and 
clearly none show, teach or suggest using such values to control the timing of frame 
transmission. Therefore Applicants submit that these dependent claims are farther 
allowable. 

Information Disclosure Statement 

Applicants are concurrently filing an Information Disclosure Statement with a 
Form 1449. Applicants request consideration of the provided materials. 
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CONCLUSION 



Based on the above remarks Applicants respectfully submit that all of the present 
claims are allowable. Reconsideration is respectfully requested. 



Wong, Cabello, Lutsch, 

Rutherford & Brucculeri, L.L.P. 
20333 SH 249. Suite 600 
Houston, TX 77070 
832/446-2405 



CERTIFICATE OF MAILING 
37 § C.F.R. 1.8 



I hereby certify that this correspondence is being deposited with the U.S. Postal 
Service with sufficient postage as First Class Mail in an envelope addressed to 
Commissioner for Patents, P.O. Box 1450, Alexandria VA, 22313-1450, on the 
date below. i 



Respectfully submitted, 



Keith Lutsch, Reg. No. 31,851 





Keith Lutsch 
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Amendment to the Drawings: 
The attached sheets of drawings replace all of the original drawings. The attached 
sheets fully conform to the requirements of the rules and are significantly more readable. 
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